The World Wide Web (the “web”), an information system of interlinked hypertext documents that are accessed using the Internet, is in a transitional phase evolving from a mechanism to transfer static documents (e.g. written using hypertext mark-up language (HTML)) towards a sophisticated platform for large-scale Web applications. This development has driven, at least in part, by the introduction of novel application program interfaces (APIs) (e.g., HTML5 JavaScript APIs) and related technologies.
One technology that is of particular significance to web applications (e.g., business applications) is the HTML5 Application Cache. The Application Cache (“App-Cache”) enables a web browser to reliably make web applications available when users are offline. That is, even if no network connection is available, an App-Cache-enabled web application can be utilized to view or process data (e.g., business critical data). In order to enable such a scenario, the required data is stored on the client-side (e.g., the user device). Because traditional web applications were not able to store data within the web browser, the so-called HTML5 Web Storage API was introduced to enable persistent client-side data storage. Such a storage mechanism can be used for the above-discussed offline scenarios, as well as for caching of larger amounts of data.
From a security point of view, the client-side storage of confidential data is very critical. By default, data that is stored within the Web Storage API is kept by the web browser for an unlimited amount of time, and is accessible to anyone who has physical access to the user device that the web browser is running on. While in the traditional web paradigm, the server is in control of the data and is able to grant or revoke access to the data at any time, data access is uncontrollable in the novel client-side case. Consequently, using the Web Storage API for such confidential data embodies a tradeoff between functionality and security. That is, either the web application waives the usage of modern technologies, or gives up control of its data, neither of which is acceptable.
Another issue is insufficient separation of data within the Web Storage API. By default, each origin (defined by protocol, port and domain) receives one dedicated storage area to store and retrieve data. To achieve this, the data is stored in a key-value fashion. Consequently, if a web application attempts to store an item, the web application selects a unique key and advises the Web Storage API to store the data under the key. If a web application seeks to retrieve the data, the web application uses the key to tell the Web Storage API which data is to be provided.
In simple web applications, this mechanism works well. However, in large-scale business applications, this behavior can lead to problems. For example, in large-scale applications there is often not only one web application running under the same origin, but potentially dozens of applications that are developed by different development teams. Consequently, it is relatively common that two applications are using the same key to store different kinds of data within the Web Storage API. As all applications are loaded from the same origin, the different applications are overwriting each other's data.
Besides this problem, there may be several standard components using these storage facilities. For example, a standard search field could use the Web Storage API to cache the last search terms or results in order to speed up the user experience. In order to benefit from code reuse, such components are developed once and then reused whenever such a functionality is needed. In large-scale applications these standard components are used extensively. Because they are based on the same code and often use the same hardcoded keys for storing data, these components also overwrite each other's data.